Does this detect upstream/downstream relationships solely from how builds are triggered, or does this also detect if a downstream build is triggered by something unrelated (e.g. cron) and then uses the copyArtifacts step to copy artifacts from an upstream build?

I'm asking because we can get hundreds of downstream builds in the copyArtifacts case and I'm concerned that looking up all of those could be excessively slow.

@KalleOlaviNiemitalo

Thanks for calling this out. I checked the implementation to make sure before replying.

This feature is trigger-based only, not artifact-based.

• Upstream detection uses CauseAction / Cause.UpstreamCause in getUpstreamBuild(...).
• Downstream detection uses DownstreamBuildAction in getDownstreamBuilds(...).
• Queued downstream items are also linked only through Cause.UpstreamCause.
• There is no copyArtifacts-specific detection logic in this feature.

So if a build starts independently, for example from cron, and then uses copyArtifacts from some other build, this implementation would not treat that build as downstream.

So the graph is following explicit build-trigger relationships, not artifact-consumption relationships.

On the performance concern, this code is not scanning all builds looking for artifact usage. It reads trigger metadata from the current build chain, and it also has hard safety caps:

• MAX_NODES = 200
• MAX_DEPTH = 50

So the case of getting hundreds of downstream builds purely because of copyArtifacts should not apply here.

That said, I do not have an exact or near-replica of your pipeline setup locally, so if you have a representative case handy, please feel free to test it. If it behaves differently in practice, I can follow up and revert or adjust the implementation as needed.

Looks awesome! 😍
Does it work when upstream triggers downstream with build step ?

I used this to re-create your screenshot:

import com.cloudbees.hudson.plugins.folder.Folder
import org.jenkinsci.plugins.workflow.job.WorkflowJob
import org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition
import jenkins.model.Jenkins

// ---------------------------------------------------------------------------
// Recreates the upstream/downstream "Build Flow" pipeline jobs under issues/1310.
//
// Wiring (upstream -> downstream). Where a job has several upstreams it gets
// triggered once per upstream, which is why e2e-tests and deploy-staging show
// up as multiple runs in the Build Flow view.
// ---------------------------------------------------------------------------

def downstream = [
    'root'              : ['frontend-build', 'backend-build', 'mobile-build'],
    'frontend-build'    : ['frontend-unit-test', 'frontend-lint'],
    'backend-build'     : ['backend-unit-test', 'backend-lint', 'backend-security'],
    'mobile-build'      : ['mobile-unit-test'],
    'frontend-unit-test': ['e2e-tests'],
    'frontend-lint'     : ['e2e-tests'],
    'backend-unit-test' : ['integration-tests'],
    'backend-lint'      : ['integration-tests'],
    'backend-security'  : ['integration-tests'],
    'mobile-unit-test'  : ['mobile-e2e'],
    'e2e-tests'         : ['deploy-staging'],
    'integration-tests' : ['deploy-staging'],
    'mobile-e2e'        : [],
    'deploy-staging'    : [],
]

def jenkins = Jenkins.get()
def rng = new Random()

// --- ensure folder path issues/1310 ---------------------------------------
def getOrCreateFolder = { ItemGroup parent, String name ->
    def existing = parent.getItem(name)
    if (existing instanceof Folder) {
        return existing
    }
    if (existing != null) {
        existing.delete() // wrong type, replace it
    }
    parent.createProject(Folder, name)
}

def issues = getOrCreateFolder(jenkins, 'issues')
def folder = getOrCreateFolder(issues, '1310')

// --- build the pipeline script for a job -----------------------------------
def scriptFor = { String name, List<String> kids ->
    def secs = 2 + rng.nextInt(7) // 2..8s so the tree completes quickly
    def sb = new StringBuilder()
    sb << "pipeline {\n"
    sb << "  agent any\n"
    sb << "  stages {\n"
    sb << "    stage('${name}') {\n"
    sb << "      steps {\n"
    sb << "        echo 'Running ${name}'\n"
    sb << "        sleep time: ${secs}, unit: 'SECONDS'\n"
    sb << "      }\n"
    sb << "    }\n"
    if (kids) {
        sb << "    stage('trigger downstream') {\n"
        sb << "      steps {\n"
        kids.each { kid ->
            // relative name resolves within the same folder
            sb << "        build job: '${kid}', wait: false, propagate: false\n"
        }
        sb << "      }\n"
        sb << "    }\n"
    }
    sb << "  }\n"
    sb << "}\n"
    sb.toString()
}

// --- create / update each job ---------------------------------------------
downstream.each { name, kids ->
    def job = folder.getItem(name)
    if (!(job instanceof WorkflowJob)) {
        if (job != null) {
            job.delete()
        }
        job = folder.createProject(WorkflowJob, name)
    }
    job.definition = new CpsFlowDefinition(scriptFor(name, kids), true)
    job.save()
    println "Configured ${job.fullName}"
}

println "\nDone. Created/updated ${downstream.size()} jobs under ${folder.fullName}."
println "Trigger the flow with:  Jenkins.get().getItemByFullName('issues/1310/root').scheduleBuild2(0)"

// Uncomment to kick off the whole tree immediately:
// folder.getItem('root').scheduleBuild2(0)

@novinxy - yes. I used that only.

I haven’t looked in detail yet and will need more time and ideally feedback from others
Some initial thoughts:

• the pipeline you are actively viewing (how it adds dashed lines) feels a bit strange to me. It took me a bit to work out why it was dashed I think this could be communicated differently.
• I’m not sure on the second widget for it on the build and job pages. Maybe there should be a button for swapping between the two widgets? I get it makes it more discoverable but we don’t want lots of widgets piled on that page as it will get full quickly

@timja

the pipeline you are actively viewing (how it adds dashed lines) feels a bit strange to me. It took me a bit to work out why it was dashed I think this could be communicated differently.

Thanks, I did think about it but left it for community feedback because couldn't decide. The following is another design which Jenkins follows widely -

WDYT about this?

I'm not sure if the others need fading out but yes some sort of border to show 'active' or 'selected' would be better

The fade out was not on select, it was on hover... I just took a screenshot at the wrong time :)

For me fade out looks clear and makes it easy to see selected "flow"
But "active" border is also nice alternative :)

Those builds on each card are stages from the pipelines ?
Do they provide links to the stages ?
What happens if there are many stages like 100 in pipeline ?

Edit: Nvm, description answered that for me. Those are recent builds

This flow shows pipeline relations, but is it easy to analyze individual flow of the builds?

I mean such situation:

• we have 3 pipelines: A, B, C
• A -> B -> C
• they already have more than 5 runs
• Scenario A: Pipeline A fails without triggering B. Last Build for A, B, C is "different build flow"
• Scenario B: Pipeline A fails but triggered B, which triggered B, C. Last Build for A, B, C is "same build flow"
• Is there option to differenciate scenario A and scenario B from those graphs ? Is it possible to track which build from pipeline A triggered which build from pipeline B?

If not then I think simple "active border" on each related run would be sufficient :)
So If I hover on one run, it will "active" and other cascade or runs will also active :)

Just for clarification -

Selected/Active border on current job

Hover fade out (can still see the current job in the left side, but faded)

Just for clarification -

Selected/Active border on current job

### Hover fade out (can still see the current job in the left side, but faded)

Maybe hover effect should be disabled if it hides active pipeline ?

But with clicking on active card maybe we could enhance it better ? What if clicking could bring out pipeline flow? That could help in analyzing flow for complicated scenarios, e.g.
Click on one pipeline shows fades out all non-related pipelines, or changes border for all related ones
If we click on frontend-lint we make "green ones" more visible

what do you think about this idea ?
Sorry if I'm proposing something really difficult, I'm not frontend guy, so I don't know how difficult are such implementations 😅

Scenario A: Pipeline A fails without triggering B. Last Build for A, B, C is "different build flow"

The build flow does not load in this case for the latest build where A failed before triggering B.

Scenario B: Pipeline A fails but triggered B, which triggered B, C. Last Build for A, B, C is "same build flow"

If A fails after triggering B, which triggered C, and if wait: true was set, that means C was finished, then B, then some steps ran which failed, so the Build Flow would load.

_We can also test these scenarios for better understanding. _

Maybe hover effect should be disabled if it hides active pipeline ?

Hover is intended for a quick glance of the flow between job nodes (one parent and one child), while being anywhere in the graph, irrespective of the selected/active job.

But with clicking on active card maybe we could enhance it better ? What if clicking could bring out pipeline flow? That could help in analyzing flow for complicated scenarios, e.g.
Click on one pipeline shows fades out all non-related pipelines, or changes border for all related ones
If we click on frontend-lint we make "green ones" more visible

The though process, and what I have seen is - Bezier curves/Connector lines are the tracking mechanisms users use to track the flow.

I would prefer not fading the whole unrelated flow based on selected job, unless there is a strong reasoning since then the "here's the whole Build Flow" core idea and glancing through functionality would break.

When I think of it..... There is an hide/show upstream/downstream toggle, perhaps there can be another one, "View Active Job Flow/name something else" which can let us view what you suggested. @novinxy WDYT about this?

Sorry if I'm proposing something really difficult, I'm not frontend guy, so I don't know how difficult are such implementations 😅

I'm also just starting out, so no idea lol... ;)

@timja @novinxy
https://github.com/user-attachments/assets/1829b836-1e7f-4d5a-ab61-ffc91c100412

Also updated it in description

@adityajalkhare ant plan to continue?

@panicking yeah. I'll pick it up after 15th July and see if I can add it to YABV's own repo if it doesn't take a lot of time.

Last I saw it had lot's of upgrade issues open.

If not I'll see if creating a new plugin in itself is a better idea.

But the Build Flow won't be a part of Pipeline Graph View as others suggested above.

@panicking yeah. I'll pick it up after 15th July and see if I can add it to YABV's own repo if it doesn't take a lot of time.

Last I saw it had lot's of upgrade issues open.

If not I'll see if creating a new plugin in itself is a better idea.

But the Build Flow won't be a part of Pipeline Graph View as others suggested above.

I think the flow should go here, I don't see any reason why this should not happen. There use case where the jobs are composed by multiple pipeline? Why the flow as a tab is not welcome?

@panicking, @janfaracik and @timja have strongly suggested to keep this flow in the OG plugin itself in #1310